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in the Application. This brief is submitted pursuant to a Notice of Appeal filed on 
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BRIEF FOR APPLICANTS - APPELLANTS 
(i) 

Real Party in Interest 
The real party in interest is International Business Machines Corporation 
(IBM), the assignee. 

(ii) 

Related Appeals and Interferences 
There are no other appeals or interferences known to appellants, 
appellants' representative or assignee, which will directly affect or be directly 
affected by or have a bearing on the Board's decision in the pending appeal. 

(iii) 

Status of Claims 

Claims 1 - 20 are finally rejected. All the rejected claims are being 
appealed. 

(iv) 

Status of Amendment 
A "Request for Reconsideration" was filed after the Final Action. However, 
it was deemed not to have put the Application in condition for allowance. 

(v) 

Summary of Claimed Subject Matter 
The invention, as claimed in Claim 1, provides a method of enhancing 
priority boosting of scheduled threads. The method comprises the steps of 
determining by a second thread being executed on a second CPU whether to 
wait for a lock on a shared resource held by a first thread that is scheduled to be 
executed by a first CPU, the second thread having a higher priority than the first 
thread; boosting the priority of the first thread by passing the higher priority of the 
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second thread to the first thread if the second thread has to wait for the lock on 
the shared resource; and enhancing the priority boosting of the first thread by 
rescheduling the first thread to run on the second CPU (see page 6, line 16 to 
page 7, line 30, Thi and Th 2 in Figs. 1a - 1f and explanation of the figures on 
page 7, line 31 to page 8, line 9). 

The invention, as claimed in Claim 6, provides a computer program 
product on a computer readable medium for enhancing priority boosting of 
scheduled threads. The computer program product comprises code means for 
determining by a second thread being executed on a second CPU whether to 
wait for a lock on a shared resource held by a first thread that is scheduled to be 
executed by a first CPU, the second thread having a higher priority than the first 
thread; code means for boosting the priority of the first thread by passing the 
higher priority of the second thread to the first thread if the second thread has to 
wait for the lock on the shared resource; and code means for enhancing the 
priority boosting of the first thread by rescheduling the first thread to run on the 
second CPU (see page 6, line 16 to page 7, line 30, Thi and Th 2 in Figs. 1a - 1f 
and explanation of the figures on page 7, line 31 to page 8, line 9). The code 
means recited in the claim are the steps enumerated on page 8, lines 10-32 
and in Fig. 2. 

The invention, as claimed in Claim 11, provides an apparatus for 
enhancing priority boosting of scheduled threads. The apparatus comprises 
means for determining by a second thread being executed on a second CPU 
whether to wait for a lock on a shared resource held by a first thread that is 
scheduled to be executed by a first CPU, the second thread having a higher 
priority than the first thread; means for boosting the priority of the first thread by 
passing the higher priority of the second thread to the first thread if the second 
thread has to wait for the lock on the shared resource; and means for enhancing 
the priority boosting of the first thread by rescheduling the first thread to run on 
the second CPU (see page 6, line 16 to page 7, line 30, Thi and Th 2 in Figs. 1a - 
1f and explanation of the figures on page 7, line 31 to page 8, line 9). The 
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means recited in the claim are the steps enumerated on page 8, lines 10-32 
and in Fig. 2 processed by processor CPUs 302, 303 and 304 of Fig. 3. 

The invention, as claimed in Claim 16, provides a system for enhancing 
priority boosting of scheduled threads. The system comprises at least one 
storage device (i.e., local memory 309 or hard disk 332) for storing code data; 
and at least two CPUs (i.e., CPUs 302, 303 and 304), one of the at least two 
CPUs for processing the code data to determine by a second thread being 
executed on the at least one CPU whether to wait for a lock on a shared 
resource held by a first thread that is scheduled to be executed by the other 
CPU, the second thread having a higher priority than the first thread, to boost the 
priority of the first thread by passing the higher priority of the second thread to 
the first thread if the second thread has to wait for the lock on the shared 
resource, and to enhance the priority boosting of the first thread by rescheduling 
the first thread to run on the second CPU (see page 6, line 16 to page 7, line 30, 
Thi and Th 2 in Figs. 1a - 1f and explanation of the figures on page 7, line 31 to 
page 8, line 9). 

(vi) 

Grounds of Rejection to be Reviewed on Appeal 
Whether it was proper to reject Claims 1-20 under 35 USC §1 03(a) as 
being unpatentable over Bak et al. in view of Gosalia et al. 



(vii) 
Arguments 

Whether it was proper to reject Claims 1-20 under 35 USC §1 03(a) as 
being unpatentable over Bak et al. in view of Gosalia et al. 
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Firstly, the Examiner did not fulfill his obligation of providing a prima facie 
obviousness rejection because the Examiner did not state what the provisional 
applications filed on 2/18/2003 disclose. 

According to MPEP 706.02(f)(1), EXAMINATION GUIDELINES FOR 
APPLYING REFERENCES UNDER §1 02(e), when an application claims priority 
benefit under 35 U.S.C. 119(e) to a prior U.S. provisional application (which the 
Gosalia et al. reference does) or claims the benefit under 35 U.S.C. 1 20 of a prior 
non-provisional application, the application is accorded the earlier filing date as 
its prior art date under 35 U.S.C. 102(e), assuming the earlier-filed application 
has proper support for the subject matter as required by 35 U.S.C. 1 19(e) or 120. 

In this particular case, the Examiner used the teachings of Bak et al. in 
combination with those of Gosalia et al. to reject the claims in a Final Action. 
Applicants filed a Request for Reconsideration in which Applicants pointed out 
that the instant Application was filed before the Gosalia et al. reference. The 
Examiner, in an Advisory Action, asserted that the Gosalia et al. reference claims 
priority benefit under 35 U.S.C. 119(e) to U.S. provisional applications filed on 
2/18/2003. 

However, the Examiner did not point out which subject matter of the 
Gosalia et al. reference was supported in the provisional applications filed on 
2/18/2003. Specifically, the Examiner did not point out whether or not the 
teachings relied upon in the Gosalia et al. reference to reject the claims were 
covered in the provisional applications filed on 2/18/2003. Therefore, the 
Examiner did not fulfill his obligations under MPEP 706.02(f)(1). 

Secondly, it is a well settled law that in considering a Section §103 
rejection, the subject matter of the claim "as a whole" must be considered and 
analyzed. In the analysis, it is necessary that the scope and contents of the prior 
art and differences between the art and the claimed invention be determined. 
Graham v. John Deere Co., 383 U.S. 1 (1966). 

Claims 1. 6. 11 and 16 
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Bak et al. purport to teach a method of locking and unlocking objects by 
threads. According to the teachings of Bak et al., a first thread is used to obtain 
a header value of an object by replacing the contents of a header field of the 
object with a sentinel that identifies an execution stack associated with the first 
thread. Once the object header field contents are replaced with the sentinel, a 
determination is made regarding whether the object header field contents include 
a header value of the object. If it is determined that the object header field 
contents do not include the header value of the object, a determination is made 
as to when the object is in the process of being studied by a second thread. If it 
is determined that the object is not in the process of being studied by a second 
thread, the method involves adding the first thread to a list associated with the 
stack associated with the second thread. The list is arranged to indicate that the 
first thread is awaiting access to the object. If, on the other hand, it is determined 
that the object is in the process of being studied by a second thread, the object 
header field contents are resolved to identify the second thread. And, it is 
determined whether an execution priority associated with the second thread is 
less than an execution priority associated with the first thread. If it is determined 
that the second thread execution priority is less than the first thread execution 
priority, the method further includes boosting the second thread execution priority 
to match the first thread execution priority. 

But Bak et al. do not teach, show or so much as suggest the step of 
enhancing the priority boosting of a first thread by rescheduling the first 
thread to run on the second CPU , the second CPU being the CPU on which 
the second thread is executing. 

Note that the step of enhancing the priority boosting of a thread is in 
addition to the step of boosting the priority of the thread. For example, on page 
7, lines 3 - 8 of the Application, it is stated that to increase the likelihood that the 
thread (e.g., Thi) that holds a lock on a resource will soon be executed, a second 
thread (e.g., Th 2 ) which is being executed and which needs to use the resource 

AUS920030439US1 



Page 6 of 17 



Appl. No. 10/682,387 

Appeal Brief 05/03/2007 

Reply to Office Action of 1 0/05/2006 

will boost the priority of the thread Thh to its priority if its priority is higher than the 
priority of thread Thi. 

Further, on page 7, line 17 - 22 of the Specification, it is disclosed that 
after the priority of thread Thi is boosted, thread Thi may still have to wait up to 
1 0 ms before it is has some processing time. 

Consequently, on page 7, lines 23 - 30 of the Specification, it is disclosed 
that after boosting the priority of thread Thi, thread Th 2 will also hand off its CPU 
time to thread Thi by pulling thread Thn into CPUi's run queue before it goes to 
sleep. This ensures that thread Thi will receive processing time right away. This 
is what is claimed as the step of enhancing the priority boosting of a first 
thread by rescheduling the first thread to run on the second CPU. 

The Examiner stated that Bak et al. teach the step of enhancing the 
priority boosting of a first thread by rescheduling the first thread to run on 
the second CPU in col. 23, lines 15 - 35 and in col. 24, lines 55 - 57. 
Applicants respectfully disagree. 

In col. 23, lines 15-35, it is disclosed: 

If it is determined in step 990 that the boost counters are equal, 
then process flow proceeds to step 992 where the obtained boosted 
thread is unboosted to the assigned priority of the boosted thread. 
Unboosting the boosted thread also generally involves 
decrementing, or otherwise updating, the boost counter associated 
with the thread. It should be appreciated that the assigned priority 
is not necessarily the priority which was associated with the 
obtained boosted thread at the time the obtained boosted thread 
was boosted by the unboosting thread. The operating system with 
which the obtained boosted thread is associated may assign a new 
priority to the obtained boosted thread at substantially any time. By 
way of example, if a first thread with an original priority of "2" is 
boosted to a priority of "6" by a second thread, and is then assigned 
a priority of "4" by the operating system, when the second thread 
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unboosts the first thread, the first thread is unboosted to a priority 
of "4." After the obtained boosted thread is unboosted in step 992, 
process flow returns to step 980 where a determination is made 
regarding whether the unboosting thread has previously boosted 
another thread which may need to be unboosted. 
Thus, in that paragraph it is stated that if, for example, thread Thi has a 
priority of 2 and is boosted to a priority of 6 by thread Th 2 , if the operating system 
later assigns a priority of 4 to thread Th^ then thread Th 2 will unboost the priority 
of thread Thi by reducing the priority of thread TTH from 6 to 4. Once that is 
done, a check will be made to determine whether thread Th 2 has boosted the 
priority of any other threads besides thread Thi. If so, a check will be made to 
determine whether any one of those threads need to have their priority reduced 
just as in the case of thread ThH . 

In col. 24, lines 54 - 60, it is disclosed: 

Bytecodes 1130 are provided to a runtime environment 1135 
which includes virtual machine 1140. Runtime environment 1135 
may generally be executed using a processor or processors such as 
CPUs 1032 of FIG. 12. Virtual machine 1140 includes a compiler 
1142, an interpreter 1144, and a runtime system 1146. Bytecodes 
1 130 may be provided either to compiler 1 142 or interpreter 1 144. 
In this cited paragraph, it is disclosed that runtime environments are 
executed by a processor. If the system is a multi-processor system, then the 
runtime environments will be executed by the processors. 

However, nowhere in the cited references is there a teaching, impliedly or 
otherwise, of the step of enhancing the priority boosting of a first thread by 
rescheduling the first thread to run on the second CPU as claimed by the 
Examiner. 

Gosalia et al., on the other hand, purport to teach a multithreaded kernel 
for a graphics processing unit. Accordingly, Gosalia et al. provide a co-processor 
that may shift contexts in order to service multiple application programs. 
AUS920030439US1 
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Specifically, Gosalia et al. teach that current co-processors typically implement 
cooperative multitasking, which is a type of multitasking wherein an application 
currently controlling the co-processor must relinquish control to other 
applications. If the application fails to relinquish control, it can effectively "hog" 
the co-processor. To solve this problem, Gosalia et al. purport to teach the use of 
a list (i.e., a queue) that is submitted to a scheduler. The scheduler then 
determines how much processing time each application is entitled to receive. 
Therefore, no one application program can "hog" the co-processor. 

However, since Gosalia et al. advocate the use of one processor (i.e., the 
co-processor), Gosalia et al. cannot (and just like in the case of Bak et al. do not) 
teach the step of enhancing the priority boosting of a first thread that is 
scheduled to run on a first CPU by rescheduling the first thread to run on 
the second CPU. 

Since, as shown immediately above, neither Bak et al. nor Gosalia et al. 
teach the step of enhancing the priority boosting of a first thread that is 
scheduled to run on a first CPU by rescheduling the first thread to run on 
the second CPU, Appellants submit that the claimed invention is allowable over 
the cited references. 

Claims 2, 7, 12 and 17 

Claims 2, 7, 12 and 17 include the limitations "wherein when the priority 
boosting of the first thread is enhanced, the first thread becomes the next thread 
to be dispatched for execution." 

The Examiner asserted that Bak et al. disclose these limitations in col. 4, 
lines 64 - 67 and in col. 5, lines 1 - 4. Appellants respectfully disagree. 
In col. 4, line 61 to col. 5, line 4, it is disclosed: 

In another embodiment, when it is determined that the 
object is in the process of being studied by a second thread, the 
object header field contents are resolved to identify the second 
thread, and it is determined whether an execution priority 
AUS920030439US1 
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associated with the second thread is less than an execution priority 
associated with the first thread. In such an embodiment, when it is 
determined that the second thread execution priority is less than the 
first thread execution priority, the method further includes boosting 
the second thread execution priority to match the first thread 
execution priority. 



In this paragraph, it is disclosed that when a thread (i.e., Th 2 ) needs to use 
a resource that has been locked by another thread (i.e., Thi), the thread Th 2 is 
first identified in order to obtain its priority. If its priority is higher than the priority 
of thread Thi, then the priority of thread Thi is boosted to that of thread Th 2 . 

But nowhere in the cited paragraph is there a teaching of the limitations 
wherein when the priority boosting of the first thread is enhanced, the first 
thread becomes the next thread to be dispatched for execution as in the 
claimed invention. 

Again, because neither Bak et al. nor Gosalia et al., alone or in 
combination, teach the invention as claimed, Appellants submit that the claims 
are patentable over the applied references. 

In view of the foregoing, Appellants respectfully request reversal of the 
rejection. 
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(viii) 

Claims Appendix 

1. (Previously presented) A method of enhancing priority boosting of 
scheduled threads comprising the steps of: 

determining by a second thread being executed on a second CPU 
whether to wait for a lock on a shared resource held by a first thread that 
is scheduled to be executed by a first CPU, the second thread having a 
higher priority than the first thread; 

boosting the priority of the first thread by passing the higher priority of the 
second thread to the first thread if the second thread has to wait for the 
lock on the shared thread; and 

enhancing the priority boosting of the first thread by rescheduling the first 
thread to run on the second CPU. 

2. (Original) The method of Claim 1 wherein when the priority boosting of the 
first thread is enhanced, the first thread becomes the next thread to be 
dispatched for execution. 

3. (Original) The method of Claim 2 wherein after the priority boosting of the 
first thread has been enhanced, the second thread relinquishes the 
second CPU by going to sleep awaiting the release of the lock by the first 
thread. 

4. (Original) The method of Claim 3 wherein after the first thread has 
released the lock, the second thread is awakened and rescheduled for 
execution by the second CPU. 
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5. (Original) The method of Claim 4 wherein after being rescheduled for 
execution by the second CPU, the second thread is likely the next thread 
to be dispatched for execution. 

6. (Previously presented) A computer program product on a computer 
readable medium for enhancing priority boosting of scheduled threads 
comprising: 

code means for determining by a second thread being executed on a 
second CPU whether to wait for a lock on a shared resource held by a first 
thread that is scheduled to be executed by a first CPU, the second thread 
having a higher priority than the first thread; 

code means for boosting the priority of the first thread by passing the 
higher priority of the second thread to the first thread if the second thread 
has to wait for the lock on the shared thread; and 

code means for enhancing the priority boosting of the first thread by 
rescheduling the first thread to run on the second CPU. 

7. (Original) The computer program product of Claim 6 wherein when the 
priority boosting of the first thread is enhanced, the first thread becomes 
the next thread to be dispatched for execution. 

8. (Original) The computer program product of Claim 7 wherein after the 
priority boosting of the first thread has been enhanced, the second thread 
relinquishes the second CPU by going to sleep awaiting the release of the 
lock by the first thread. 
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9. (Original) The computer program product of Claim 8 wherein after the first 
thread has released the lock, the second thread is awakened and 
rescheduled for execution by the second CPU. 

10. (Original) The computer program product of Claim 9 wherein after being 
rescheduled for execution by the second CPU, the second thread is likely 
the next thread to be dispatched for execution. 

11. (Previously presented) An apparatus for enhancing priority boosting of 
scheduled threads comprising: 

means for determining by a second thread being executed on a second 
CPU whether to wait for a lock on a shared resource held by a first thread 
that is scheduled to be executed by a first CPU, the second thread having 
a higher priority than the first thread; 

means for boosting the priority of the first thread by passing the higher 
priority of the second thread to the first thread if the second thread has to 
wait for the lock on the shared thread; and 

means for enhancing the priority boosting of the first thread by 
rescheduling the first thread to run on the second CPU. 

12. (Original) The apparatus of Claim 1 1 wherein when the priority boosting of 
the first thread is enhanced, the first thread becomes the next thread to be 
dispatched for execution. 

13. (Original) The apparatus of Claim 12 wherein after the priority boosting of 
the first thread has been enhanced, the second thread relinquishes the 
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second CPU by going to sleep awaiting the release of the lock by the first 
thread. 

14. (Original) The apparatus of Claim 13 wherein after the first thread has 
released the lock, the second thread is awakened and rescheduled for 
execution by the second CPU. 

15. (Original) The apparatus of Claim 14 wherein after being rescheduled for 
execution by the second CPU, the second thread is likely the next thread 
to be dispatched for execution. 

16. (Previously presented) A system for enhancing priority boosting of 
scheduled threads comprising: 

at least one storage device for storing code data; and 

at least two CPUs, one of the at least two CPUs for processing the code 
data to determine by a second thread being executed on the at least one 
CPU whether to wait for a lock on a shared resource held by a first thread 
that is scheduled to be executed by the other CPU, the second thread 
having a higher priority than the first thread, to boost the priority of the first 
thread by passing the higher priority of the second thread to the first 
thread if the second thread has to wait for the lock on the shared thread, 
and to enhance the priority boosting of the first thread by rescheduling the 
first thread to run on the second CPU. 

17. (Original) The system of Claim 16 wherein when the priority boosting of 
the first thread is enhanced, the first thread becomes the next thread to be 
dispatched for execution. 
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18. (Original) The system of Claim 17 wherein after the priority boosting of the 
first thread has been enhanced, the second thread relinquishes the 
second CPU by going to sleep awaiting the release of the lock by the first 
thread. 



19. (Original) The system of Claim 18 wherein after the first thread has 
released the lock, the second thread is awakened and rescheduled for 
execution by the second CPU. 

20. (Original) The system of Claim 19 wherein after being rescheduled for 
execution by the second CPU, the second thread is likely the next thread 
to be dispatched for execution. 
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(ix) 

Evidence Appendix 



None. 
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(x) 

Related Proceedings Appendix 



None. 
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